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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 



Introduction 



The present document is a consequence of the ETSI BSM report and recommendations on performance, availability and 
quality of service detailed in [i.l]. It was deemed to be important to have an own document about performance 
parameters even if this was not foreseen in [i.l]. 

BSM networks may be stand-alone domains, serving IP end-hosts located behind satellite terminals, but may often be 
connected to external terrestrial segments. Users of BSM networks require their applications to run satisfactorily over 
the whole end-to-end path, and thus over the satellite links, as well as over the traversed terrestrial segments. The 
performance of the user applications can be derived by the network performance levels provided by the underlying 
networks traversed by the end-to-end path, and since the terrestrial segments connected to the BSM networks, often 
provide measurable network performance levels, it is fundamental to specify network performance levels for the BSM 
systems in the same way as for terrestrial networks. In addition a network whose performance is not measurable cannot 
sell its services, thus the performance levels required from BSM networks need to be formalized in a set of performance 
parameters that can be used to check fulfilment of contractual agreements. 
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Scope 



The present document defines performance parameters which will be used in BSM networks for the four functions 
mentioned below, i.e. for measuring performance, monitoring, controlling and analysing BSM systems. 

Performance management is meant by ITU as one of the five network management categories, FCAPS, as specified by 
the ITU-T Recommendation M.3400 [i.4]. So, adopting the ITU terminology, the present document focuses on 
"Performance Parameters" as meant by the ITU and so all parameters relevant for the four remaining network 
management categories (Fault management. Configuration management. Accounting management and Security 
management) will not be considered here. ITU-T Recommendation M.3400 [i.4] also defines performance management 
as consisting of the following functions: 



• 



Performance Quality Assurance. 

• Performance Monitoring. 

• Performance Management Control. 

• Performance Analysis. 

These parameters can be used, for example, by a BSM network manager to establish QoS levels for a given service, and 
monitor the "health" of the BSM, or to "present" the performance of the BSM network in order to assess compliancy to 
some contractual agreements. The parameters could be used as a basis for one or more MIBs. 

According to TR 121 905 [i.23], "Network performance parameter values are usually derived from Quality of Service 
(QoS) parameter values". Therefore BSM performance parameters will be derived from all QoS parameters relevant to 
BSM networks, namely from the classical parameters for IP-based services, e.g. proposed by ITU [i.4], as well as from 
more BSM-specific ones, coming from the definition of the BSM QoS architecture [1],[2] and [3]. 

Network performance parameters may be used for different purposes: they can be used only inside the BSM network or 
can be exposed to BSM external interfaces; this will be also clarified in the present document. In the former case they 
will refer to SI-SAP properties (e.g. related to Queue Identifier (QID)) and thus they are meant for BSM-internal use 
only; in the latter case they can be presented by the satellite network operator to the outside world (e.g. external 
terrestrial network operators connected to the BSM), e.g. to prove fulfilment of contractual agreements. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

■ For a specific reference, subsequent revisions do not apply. 

■ Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 



The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 462: "SatelHte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); QoS Functional Architecture". 

[2] ETSI TS 102 463: "SatelHte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Interworking with IntServ QoS". 

[3] ETSI TS 102 464: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Interworking with DiffServ QoS". 

[4] ETSI TS 102 672: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM); Management Functional Architecture". 

2.2 Informative references 

The following referenced documents are not essential to the use of the ETSI deliverable but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

.1] ETSI TR 102 157: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia; 

IP Interworking over satellite; Performance, Availability and Quality of Service". 

.2] ITU-T Recommendation Y.1540 (former 1.380): "Internet protocol data communication service - 

IP Packet Transfer and Availability Performance Parameters", November 2007. 

.3] ETSI TS 102 295: "Satelhte Earth Stations and Systems (SES); Broadband Satellite Multimedia 

(BSM) services and architectures; BSM Traffic Classes". 

.4] ITU-T Recommendation. M.3400: "TMN management functions". 

.5] ITU-T Recommendation Y.1541 (former 1.381): "IP Performance and Availability Objectives and 

Allocations", January 2001. 

.6] ITU-T Recommendation M.2301: "Performance objectives and procedures for provisioning and 

maintenance of IP-based networks", July 2002. 

.7] IETF RFC 2330: "Framework for IP Performance Metrics". 

.8] IETF RFC 2678: "IPPM Metrics for Measuring Connectivity". 

.9] IETF RFC 2679: "A One-way Delay Metric for IPPM". 

.10] IETF RFC 2680: "A One-way Packet Loss Metric for IPPM". 

.11] IETF RFC 268 1 : "A Round-trip Delay Metric for IPPM" . 

.12] IETF RFC 3148: "A Framework for Defining Empirical Bulk Transfer Capacity Metrics". 

.13] IETF RFC 3357: "One-way Loss Pattern Sample Metrics". 

.14] IETF RFC 3393: "IP Packet Delay Variation Metric for IPPM". 

.15] IETF RFC 4656: "A One-way Active Measurement Protocol (OWAMP)". 

.16] IETF RFC 4737: "Packet Reordering Metrics". 

.17] IETF RFC 5136: "Defining Network Capacity". 

.18] IETF RFC 3418: "Management Information Base (MIB) for the Simple Network Management 

Protocol (SNMP)". 



£75/ 



7 ETSI TS 1 02 673 V1 .1 .1 (2009-1 1 ) 

[i.l9] IETF RFC 3917: "Requirements for IP Flow Information Export (IPFIX)". 

[i.20] IETF RFC 5101: "Specification of the IP Flow Information Export (IPFIX) Protocol for the 

Exchange of IP Traffic Flow Information". 

[i.21] IETF RFC 5102: "Information Model for IP Flow Information Export". 

[i.22] IETF RFC 5153: "IPFIX Implementation GuideUnes". 

[i.23] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP TR 
21.905)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Destination host (DST): host and a complete IP address where end-to-end IP packets are terminated 

NOTE: In general a host may have more than one IP address; however, a destination host is a unique association 
with a single IP address. Destination hosts also terminate higher layer protocols (e.g. TCP) when such 
protocols are implemented (taken from [i.2]). 

link: point-to-point (physical or virtual) connection used for transporting IP packets between a pair of hosts. It does not 
include any parts of the hosts or any other hosts; it operates below the IP layer 

NOTE: For example, a link could be a leased line, or it could be implemented as a logical connection over an 

Ethernet, a frame relay network, an ATM network, or any other network technology that functions below 
the IP layer (taken from [i.2]); in the BSM case the whole satellite connection from the ingress ST to the 
egress ST can be defined as a link, if the satellite or the hub, connecting the two STs, do not implement 
the IP layer. 

host: computer that communicates using the Internet protocols 

NOTE: A host implements routing functions (i.e. it operates at the IP layer) and may implement additional 
functions including higher layer protocols (e.g. TCP in a source or destination host) and lower layer 
protocols (e.g. Ethernet) (taken from [i.2]). An ST is a particular host which does not implement higher 
layer protocols. 

Measurement Point (MP): boundary between a host and an adjacent link at which performance reference events can 
be observed and measured (taken from [i.2]) 

NOTE: In general one Measurement Point (MP) for the performance parameters considered in a BSM network 
(also defined BSM MP) always coincides with one unique unicast IP address; so, where the SI-SAP is 
implemented (e.g. in an ST or in the hub), it also coincides with the unicast BSM_ID. Standard IP 
properties can be observed at BSM MPs, as well as SI-SAP specific properties, which are more related to 
SD events. 

Network Control Centre (NCC): equipment at OSI Layer 2 that controls the access of terminals to a satellite network, 
including element management and resource management functionality 

Network Performance (NP): ability of a network or network portion to provide the functions related to 
communications between users; it contributes to service accessibility, service retainability and service integrity 

NOTE: Network performance parameter values are usually derived from quality of service (QoS) parameter 
values (taken from TR 121 905 [i.23]). 
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Network Section (NS): set of hosts together with all of their interconnecting links that together provide a part of the IP 
service between a SRC and a DST, and are under a single (or collaborative) jurisdictional responsibility 

NOTE: These hosts typically have the same network identifier in their IP addresses. Typically, they have their 
own rules for internal routing. Global processes and local policies dictate the routing choices to 
destinations outside of this network section. These network sections are typically bounded by routers that 
implement the IP exterior gateway protocols (taken from [i.2]). The BSM network is a particular Network 
Section. 

population of interest: total set of packets transmitted between one (or more) ingress ST(s) and one (or more) egress 
ST(s), which are object of measurement 

NOTE: The description of the population of interest, in any statement about measured performance, should 
normally include associated QoS information, namely which packet type(s) are included in the 
population, since performance will differ by packet type. 

packet transfer reference event: event occurring when a packet crosses a measurement point (MP), so when it enters 
or leaves an IP level, normally crossing the SI-SAP 

router: host that enables communication between other hosts by forwarding IP packets based on the content of their IP 
destination address field (taken from [i.2]) 

NOTE: In a BSM network the hub or the satellite may act as routers. 

Source host (SRC): host and a complete IP address where end-to-end IP packets originate 

NOTE: In general a host may have more than one IP address; however, a source host is a unique association with 
a single IP address. Source hosts also originate higher layer protocols (e.g. TCP) when such protocols are 
implemented (taken from [i.2]). 



3.2 



Abbreviations 



For the purposes of the present document the following abbreviations apply: 

BSM MP Measurement Point for the performance parameters considered in a BSM networks 

BSM Broadband Satellite Multimedia 

CRA Constant Rate Assignment 

CRA Constant Rate Assignment 

DST Destination host 

DVB-RCS Digital Video Broadcasting Return Channel via Satellite 

FCA Free Capacity Assignment 

FCA Free Capacity Assignment 

GPS Global Positioning System 

ICMP Internet Control Message Protocol 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPDV IP Packet Delay Variation 

IPER IP Packet Error Ratio 

IPFIX IP Flow Information Export 

IPLR IP Packet Loss Ratio 

IPPG IP Packet Goodput 

IPPM IP Performance Metrics 

IPPT IP Packet Throughput 

IPRR IP Packet Reordered Ratio 

IPSA IP Service Availability 

IPTD IP Packet Transfer Delay 

MIB Management Information Base 

MP Measurement Point 

NCC Network Control Centre 

NMC Network Management Centre 

NP Network Performance 

NS Network Section 

OSI Open Standards Institute 

OWAMP One-Way Active Measurement Protocol 
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QID Queue IDentifier 

QoS Quality of Service 

RFC Request For Comments 

RSCT DVB-RSC Terminal 

RSCT DVB-RSC Terminal 

RTT Round Trip Time 

SD Satellite Dependent 

SIPR Spurious IP Packet Rate 

SI-SAP Satellite Independent-Service Access Point 

SLA Service Level Agreement 

SNMP Simple Network Management Protocol 

SNR Signal-to-Noise Ratio 

SNR Signal-to-Noise Ratio 

SRC Source host 

ST Satellite Terminal 



Overview 



There are similarities between the ETSI, ITU and IETF definitions which allow us to decide that BSM performance 
parameters will be derived mainly from QoS parameters, and in addition from other aspects needed to establish and 
maintain BSM network operation. 

The network layer (i.e. IP layer) parameters are considered to be independent of the BSM and to be well-known for 
typical IP hosts. These are the parameters that may have to be presented by the BSM network operator to external 
parties, they can be specified following ITU recommendation (e.g. [i.2]). 

Instead there are other parameters, which will be specific to the BSM, they will be available at the SI-SAP and relate to 
lower protocol layers; they will be used for BSM-internal use. 

The parameters presented in the present document represent real-time measured properties of a selected BSM entity (an 
ST or a QID); specification of numerical objectives or monitoring thresholds for these BSM performance parameters is 
left to implementers and operators. 



5 BSM Performance Parameters Context 

The BSM performance parameters always refer to BSM elements (e.g. STs) or to portions of the BSM network. 
Measurement Points (MPs) for these performance parameters (the BSM MPs) are in general associated to unique 
unicast IP addresses: A BSM MP can be defined at every layer-2 service access point in an IP host belonging to a BSM 
network (e.g. an ST, a hub, or even the satellite if it implements on-board routing). As a consequence BSM MPs 
coincide with SI-SAPs, in the hosts where the SI-SAP is implemented. This means that standard IP properties can be 
observed at BSM MPs, as well as SI-SAP specific properties, which are more related to SD events. 

More formally a BSM MP is the boundary between a host and an adjacent satellite link at which performance reference 
events can be observed and measured (taken from [i.2]). In general a BSM MP always coincides with one unique 
unicast IP address; so, where the SI-SAP is implemented (e.g. in an ST or in the hub), it also coincides with the unicast 
BSM_ID. Standard IP properties can be observed at BSM MPs, as well as SI-SAP specific properties, which are more 
related to SD events. 

Figure 5.1 shows the terminology to be used for BSM performance parameters according to the definitions given in 
clause 3.1. 
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BSM 

Measurement 

Point (MP) 



BSM MP 



Figure 5.1 : Terminology for BSIVI performance parameters 

The BSM parameters can be classified in two groups, which are more clearly described in the next two clauses and 
listed in detail in clauses 6 and 7 respectively: 

• BSM SI-SAP parameters: They are specific to the BSM, i.e. will be available at the SI-SAP and relate to 
lower protocol layers; they do not refer to IP-level performance, but to more specific properties of one 
terminal, or of one service class being provided on one particular link. 

• BSM IP parameters: They are the typical IP-layer parameters, defined in a way similar to ITU [i.2], but with 
respect to a specific BSM section or a BSM link between two given devices (e.g. between two STs). 

Considering this classification, each BSM MP may be interpreted as two virtual measurement points, one for QIDs (at 
the SI-SAP), which is to be considered for BSM SI-SAP parameters, and which does not exist is the SI-SAP is not 
implemented, and one for IP (immediately above the SI-SAP), which is to be considered for BSM IP parameters, and 
which always exists. Anyway, since physically these two virtual MPs are co-located at the ST layer-2 service access 
point, this distinction will not be done in the following. 

5.1 BSM SI-SAP performance parameters 

The BSM SI-SAP parameters are referred to a single MP, and can only be defined where the ingress (or transmitting) 
SI-SAP is implemented, so they are referred to a single ingress SI-SAP (and thus equivalently to a single unicast 
BSM_ID, being the source BSM_ID always the unicast BSM_ID of the ST). These parameters are not measured on a 
network section but on an MP at the uplink ST. 

These performance parameters describe some SD characteristics of the ST, so they are very BSM specific. They are 
used for BSM internal purposes, in particular for the management of the QoS and of the QIDs [2] and [3], since in BSM 
networks performance is usually directly linked to the characteristics of the satellite transmission (physical and link 
layer) that directly affect the BSM capabilities to operate. 



ETSI 



1 1 ETSI TS 1 02 673 V1 .1 .1 (2009-1 1 ) 

For all parameters in this group the MP is any point in the BSM network where the SI-SAP interface is implemented, 
so, in principle, at every ST. For this reason it is likely that they will be physically stored next to the "managed 
element", and that in order to get these parameters a BSM central network management system will have to interrogate 
the STs (see also [4], in Figure 7-3 the database located at the ST/NCC). 

It is useful to highlight the uplink and downlink satellite resources to which these parameters refer, depending on how 
they are considered. In general, being these parameters linked to one single SI-SAP, and considering that QIDs and SD 
queues are not implemented on the satellite receiving interface of an ST, the BSM SI-SAP parameters only carry 
information about the satellite uplink (or the traffic offered to the satellite uplink), and they do not say anything about 
the downlink. These parameters are measured on an MP at the uplink ST, so the transmitted uplink traffic they describe 
receives, in the downlink, unknown treatments, it may be directed to the hub, to another ST, and to one or several 
downlink beams at the same time. In conclusion we can state that: 

• in a star topology: 

if defined in a simple ST (not acting as hub), the BSM SI-SAP parameters refer to uplink traffic coming 
from a single IP traffic class (i.e. a QID) in one single terminal (or an aggregation of multiple QIDs 
coming from a single ST); 

if defined in the hub, the BSM SI-SAP parameters refer to uplink traffic coming from the hub, which 
may be directed to one single ST in the downlink, or which may be aggregated uplink traffic directed to 
multiple STs in the downlink (also to different beams). 

• in a mesh topology (where there is no hub station): 

the BSM SI-SAP parameters refer to uplink traffic, which may be directed to one single ST in the 
downlink, or which may be aggregated uplink traffic directed to multiple STs in the downlink (also in 
different beams). 

5.2 BSM IP performance parameters 

BSM IP performance parameters are related to IP properties, they are inspired from ITU-T Recommendations [i.2], they 
are observed at IP level (i.e. MPs are associated to IP addresses). The IP packets to be considered for the measurement 
of BSM IP parameters are called "population of interest", following ITU terminology. More details are given in 
clause 7. The BSM IP performance parameters are always measured between two BSM MPs (see also clause 7). 

They can be measured in different ways (normally on demand) by a central network management system; for this 
reason, it is likely that they will be physically stored in a central "network monitoring server" (see also [4], in Figure 7.3 
the database located at the BSM Management System). Suggestions on how to measure these parameters are also given 
in clause 7. 

As it was done for the BSM SI-SAP parameters, it is useful to highlight the uplink and downlink satellite resources to 
which these parameters refer, depending on how they are considered. The BSM IP parameters operate at IP level, they 
are associated to IP addresses, this means that all possible combinations of IP addresses in the ingress MP and egress 
MP can be suitable measurement scenarios for these parameters. For instance with these parameters it is possible to 
monitor one IP connection between two specific IP addresses of two STs, but it is also possible, e.g. at the hub, to 
describe IP packets population of interest in a way such to monitor more global issues: by knowing the IP addresses of 
the STs located in one beam, the hub could monitor performance of aggregated beam traffic (aggregated throughput 
from/to one beam, average packet transfer delay for one beam, etc.). 
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6.1 



BSM SI-SAP Performance Parameters 



Introduction 



This clause describes in detail all BSM SI-SAP performance parameters and their characteristics. 

For all parameters listed in this clause the MP is any point in the BSM network where the SI-SAP interface is 
implemented, so, in principle, at every ST (including the hub). Only "transmitting" STs can be considered for this type 
of parameters, as they measure performance on the ingress SI-SAP interface, i.e. the one which is injecting traffic into 
the BSM network. 

The Entity Relationship Diagram in Figure 6.1 summarizes the BSM SI-SAP performance parameters defined in this 
clause and their logical hierarchy. 



ST 



SI-SAP 



1:1 



1:1 



SI-SAP-level 
Pert. Param. 



Number of active QIDs [Wqid]- 

ListofQIDs[QID,]. 

Available Data Rate [RavJ- 

AII-QIDs Transmission Delay [Dj]- 

AII-QIDs Maximum Hardware Delay [C^wl- 

AII-QIDs Rate [fi]. 

AII-QIDs Slack Term [S]. 



1:N 



1:N 



QID 



M:1 



L3IP 
queue 



N:1 



1:1 



1:1 



L2SD 
queue 



Q ID-level 
Perf. Param. 



-Time from last QID modification [f^oJ 
"Type of last QID modification [mQiQ,] 
-Transmission Delay [Df] 
-Maximum Hardware Delay [D^J 
-Rate [R] 
-Slack Term [S\ 



— Traffic Pattern [r, b, p, m, M\ 

Figure 6.1 : Entity Relationship Diagram for the BSIU! SI-SAP performance parameters in an ST 

Figure 6.1 identifies the parameters which are defined at the SI-SAP level and the ones which are defined at the QID 
level. The SI-SAP level parameters include some "All-QIDs" parameters which are derived from the corresponding 
QID level parameters but represent a measurement across all the active QIDs at that SI-SAP. 

It is also possible to see the logical relation between QIDs and IP and SD queues (according to what defined in [2]) and 
thus to derive the properties inherited from SD queues to QIDs, and consequently from QIDs to IP queues. In this 
respect it should be noted from the figure that an IP queue should typically be associated with only 1 QID but (as 
shown) it may be associated to M QIDs only in the case that the M QIDs are associated with M different destination 
BSM_IDs (see [2]). As a consequence the relationship from SD properties to IP queues can be unambiguously derived. 
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For each of these parameters, some suggestions are also given on how to measure them. In any case it is assumed that 
they are estimated locally at the ST and that they are also stored locally. Their values represent instantaneous 
parameters, so in case they have to be communicated to a central NMC they will always represent the "current" value of 
the metric to be measured; each one of them is the result of a single measurement, which is stored locally to the ST until 
a new measurement is performed. It may be possible to store locally in the ST not just the current value of the 
parameter, but some past samples and to pre-process these measurements (or e.g. measurements performed at the same 
time but over different QIDs) in order to make some statistics and, if needed, to provide the NMC with more 
information. In any case these extensions, as well as further considerations on the time resolution of the measurements, 
are left to implementers and operators. 

Finally it is important to recall that QIDs are normally not sent over air, but the reference between SD resources and 
local QIDs should be known to the ST. QIDs can be freely defined at the ST to sub-divide specific SD allocation 
classes, and this can be done according to the needs of the performance management; thus the following SI-SAP 
performance parameters may refer to different types and amount of SD resources, depending on how the associated 
QIDs are defined. Since grouping pools of SD resources in one QID is not possible (according to [2]), the only 
possibility to monitor parameters over groups of SD resources is to process (e.g. summing or averaging) the parameters 
referring to multiple QIDs. 



6.2 Number of active QIDs [A/qid] 

Each ST should keep track of the creation and release of QIDs, so that at any time it can be interrogated on the number 
of active QIDs. 

This parameter is related to: 

• An SI-SAP. 

6.3 List of QIDs [QIDJ 

This parameter represent the list of all 24-bits queue identifiers (QIDs) for the A^qid QIDs currently active at the 
BSM_ID: {QID., /=l,...,iVQio}- 

This parameter is related to: 

• An SI-SAP. 



6.4 Available Data Rate [f?ava] 



This parameter is the satellite capacity available for resource allocation, measured in bytes of IP datagram (including 
headers) per second at a given ST. This capacity is what is normally used for best effort traffic or for Free Capacity 
Assignment (in DVB-RCS), and it may be important for the BSM network management to know how much capacity is 
being used by each ST for these types of traffic, and thus potentially available for allocation. 

By knowing the maximum data rate available to each ST for resource allocation, Rj^r^^ (which is normally decided by 
the Satellite Network Operator), and the capacity Rj already allocated to the ST for the i-th QID, then the available data 
rate, R.^^^, can be easily calculated as: 



^ava -^max-^^' 



Each ST can easily derive this parameter, by keeping track of the creation and release of QIDs. 
Thus this parameter is not related to any QID, but to the overall satellite link capacity. 
This parameter is related to: 
• An SI-SAP. 
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6.5 List of IP flows associated to a QID [IP(QID/)] 

For each QID a list of IP queues associated to that QID should be kept, the IP-to-QID mapping table (according to the 
definitions in [2]). This information can be exploited to inform a central server (e.g. NMC) on the way QIDs are used 
locally to the ST. 

This parameter is related to: 

• A QID. 

6.6 List of SD queues associated to a QID [SD(QID/)] 

For each QID a list of SD queues associated to that QID should be kept, the QID-to-SD mapping table (according to the 
definitions in [2]). The type of label to represent the SD queue (e.g. the MPEG PID) should be known to the ST and to 
the central server. This information can be exploited to inform a central server (e.g. NMC) on the way QIDs are used 
locally to the ST. 

This parameter is related to: 

• A QID. 

6.7 Time [fmod] and type [/?7qid] of last QID modification 

These two parameters represent the time (in hundredths of a second) a specific QID in the ST was last modified, and the 
type of QID modification event (creation, release or modification) last occurred. 

Each ST should keep track of the time each QID is created (opened), released (closed), and modified with a resolution 
of at least one hundredth of a second. For each QID the ST should store the time of the last modification event 
(creation, release, or modification), and the type of event last occurred: creation (OPEN), release (CLOSE), or 
modification (MODIFY). For QIDs, which remain open and not modified for longer than a maximum tracking time 
(which may be linked to the number of bits reserved in a MIB for the parameter), the ST should store a default value 
(e.g. 0x0); for the case of a QID closed for longer than a maximum tracking time, the ST should delete the stored data; 
so occurring time of events older than this maximum tracking time should not be kept. Considering the use that might 
be done of this information (e.g. tracking of the latest connections setup by the ST), the time reference does not need to 
be of high precision, the accuracy of ST internal clocks is considered enough. 

This parameter is related to: 

• A QID. 



6.8 Transmission Delay [Ch] 



This parameter represent the next-hop transmission delay, it is the time needed to transmit 1 bit over the SI-SAP across 
the BSM system, the value includes the propagation delay up to the egress ST, and it does not include the IP queuing 
delay in the ingress ST. This parameter can be approximated by equating it to the propagation delay. 

This parameter is normally needed by IntServ, so it is assumed that it must be known to the ST by some means, even if 
it clearly does not represent a parameter which is observed at a single MP (but normally should be measured between 
two MPs). It can be gathered in different ways (see also later in clause 7.1), with different degrees of precision. 
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For example, if this parameter is not known to the ST, it can be estimated by the ST (thus without involving a second 
MP) by means of simple probes, e.g. ICMP "echo request" packets (i.e. pings). Considering that in geostationary 
satellite networks the propagation delay is much bigger than the time needed to transmit such small packets onto the 
satellite interface and to process the reply, the transmission delay, Dj, can be well approximated by half of the 
measured round trip time (RTT). So, if we define L = L as the length in bits of the ICMP "echo request" and "echo 
reply" (224 bits), R^ as the transmission rate available on the considered /-th QID, D,- as the propagation delay to the 
egress ST associated to the /-th QID, and 5p as the processing time needed to prepare the ICMP "echo reply" (in the 
order of )is.), then it results quite straightforward that the following approximation holds already for values of Rj of 
100 Kbits to 200 Kbit/s: 

L L 

KIT. ^^^+D.+S+^^ + D,^ 2D. ■ 

ping n ^ R 

and so we can consider: 

T 2 P'"g 

Of course this approximation in the estimation of Dj introduces an error which may not be acceptable in some cases. 

The transmission delay parameter Dj is clearly associated to a QID and in particular to an egress destination ST (if it 
cannot be derived from the QID itself), since the propagation delay changes depending on the position of the ingress 
and egress STs within the satellite beam. 

This parameter is related to: 

• a QID; and/or 

• all QIDs at the SI-SAP (i.e. the full set of QIDs currently active on the SI-SAP). 

In both cases, if the egress ST of the QID, or of the set of QIDs, is not unique, then the highest possible delay of all 
egress STs should be taken. 

6.9 Maximum Hardware Delay [Dhw] 

This parameter is the worst case deviation between the time a packet is selected for transmission over the SI-SAP and 
the time its transmission over the satellite air interface actually starts. A variety of factors in the implementation of an 
ST will influence the value of this parameter (e.g. output schedulers and internal node design), but the value does not 
include IP queuing delay and the delay required to transmit the packet over the satellite. 

This parameter is needed by DiffServ. It should be known to the ST, which can easily measure it, as it is only affected 
by factors which are internal to the ST. It is suggested to do some averaging of the different measures of the parameter 
to estimate a good value of D^.^. 

This parameter is related to: 

• a QID; and/or 

• all QIDs at the SI-SAP (i.e. the full set of QIDs currently active on the SI-SAP). 

If defined for the full set of QIDs Q = jQID^ | , then it should represent the maximum value of Dj^^ in the set: 



D,„:=max{D,„,„QID,€e}. 
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6.10 Rate [HI 



1) The rate R represents the currently provided transmission rate at the SD layer, measured in bytes of IP 
datagram per second. 

2) It can be measured as the total number of bytes of IP datagrams (including headers) transmitted over the 
satellite interface for a given QID divided by the time interval duration (or equivalently, the number of bytes 
of IP datagrams transmitted for a given QID per second). 

3) Since normally in a QID the QIDSPEC parameter R represents the minimum transmission rate guaranteed to 
that QID, a possibility for a network management system to monitor this QID property is to set a threshold to 
the nominal minimum rate R*-, associated to that QID, and to trigger an alert if the measured value R becomes 
smaller than/?*. 

This parameter is related to: 

• a QID; and/or 

• all QIDs at the SI-SAP (i.e. the full set of QIDs currently active on the SI-SAP). 

If defined for the full set of QIDs Q = jQID^. | then it should represent the sum of all R^ values of the QIDs in the set: 



QID, 6 Q 



6.11 Slack Term [S] 



1) The slack term S defines the packet queuing delay associated with a QID, i.e. the time the packet spends in the 
ST at the outgoing satellite interface waiting for being selected for transmission, this includes all components 
such as buffering delay, delay due to header processing, delay due to competition with other traffic classes, 
etc. 

2) The parameter should be known to the ST, which can measure it as the time difference (t2 - 1^) between the 
time f J a packet arrives at the ST and the time ^2 the same packet is transmitted over the satellite interface. It is 
suggested to do some averaging of the different measures of the parameter to estimate a good value of S. 

3) Since normally in a QID the QIDSPEC parameter S represents the maximum expected packet queuing delay 
estimated for that QID, a possibility for a network management system to monitor this QID property is to set a 
threshold to the nominal maximum queuing delay S*, associated to that QID, and to trigger an alert if the 
measured value S becomes higher than S*\ 

This parameter is related to: 

• a QID; and/or 

• all QIDs at the SI-SAP (i.e. the full set of QIDs currently active on the SI-SAP). 

If defined for the full set of QIDs Q = jQID^ | then it should represent the maximum value of S in the set: 

5:=max{5,,QID,ee|. 



6.12 Traffic Pattern [r, b, p, m, M\ 



Some parameters attempt to characterize the throughput capacity of the satellite link at the ST, i.e. its ability to sustain a 
given IP packet transfer rate (see clause 7.3). This property is actually influenced by the traffic pattern which is offered 
to the ST, or, more specifically, to a given QID in the ST. So the traffic pattern offered to the ST should be described 
since the ability of the BSM network to successfully deliver these packets depends on this traffic. 
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The following parameters are associated to a QID, and describe the pattern of the traffic which is mapped onto that 
QID, they are the parameters of a token bucket traffic source which bounds the real traffic pattern: 

Token Bucket Rate [r] (32-bit IEEE floating point number), measured in bytes of IP datagram per second. 

Token Bucket Size [b] (32-bit IEEE floating point number), measured in bytes of IP datagram. 

Peak Data Rate [p] (32-bit IEEE floating point number), measured in bits of IP datagram per second. 

Minimum Policed Unit [m] (32-bit integer), measured in bytes. 

Maximum Packet Size [M] (32-bit integer), measured in bytes. 

This set of parameters is related to: 

• A QID. 

7 BSM IP Performance Parameters 

This clause defines a set of network performance parameters based on parameters observable at any IP-level MP in a 
BSM network, so at any point in the BSM network where the IP layer is implemented: the STs, the hub station (if any), 
the satellite (if it implements on-board routing), and the NCC/NMC. They are called BSM IP performance parameters, 
since they reflect classical ITU IP parameters [i.2]; they could be used as part of SLA (Service Level Agreement) 
specifications. 

These parameters, differently from the BSM SI-SAP ones that can be estimated and stored locally in an ST, need to be 
calculated by comparing data and measurements performed at different observation points in the BSM network (e.g. the 
delay metrics between an ingress and an egress MP). If on one side this makes the practical estimation of these metrics 
in general more complex, also considering the characteristics of satellite networks (see also next clause 7.1), on the 
other hand it gives a lot of flexibility and possibilities in measuring different parts and properties of the BSM network. 

These IP performance parameters are defined without reference to a particular service level, QoS guarantee (DSCP, 
protocol, packet type, etc.), or higher-layer protocol (TCP, UDP, etc.). These parameters, which characterize the IP 
packets object of the measurement, have to be specified when performing the measurement, in the so-called population 
of interest. Performance will differ for different QoS levels, destinations, etc., and so statements about measured 
performance should include the associated description of the population of interest. For example the population of 
interest could specify: the source IP address (it may also be "any"), the destination IP address (it may also be "any"), 
and a given DSCP. 

For the measurement of these parameters, no distinction is made between different phases of an IP packets transfer 
(i.e. Access, User Information Transfer, and Disengagement, as done in ITU [i.2]), but all the IP packets matching the 
description of the population of interests are considered object of the measurement. 

Among the IP performance parameters recommended by ITU [i.2], only a few ones are not included in the present 
document, because considered not very relevant for satellite networks, namely: IP packet severe loss block ratio (used 
to identify IP path changes due to routing updates, which cause significant bursts of lost IP packets), replicated IP 
packet ratio (used to estimate the number of replicated IP packets), and IP packet duplicate ratio (used to estimate the 
number of replicas of the replicated IP packets). 

7.1 Measuring BSM IP Performance Parameters 

Although the BSM IP parameters represent very classical metrics for IP networks, the way to measure these parameters 
is not straightforward in general, and it may not be trivial at all in satellite networks, mainly for the following reasons: 

• Chattiness: exchange of additional data over the satellite has always to be done with care. 



• 



Scalability: a central server collecting data from a number of observation points in a BSM network may have 
the need to distinguish some thousands of metering processes. 
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• Timestamp synchronization: for STs, which are very far from each other and which can only be reached 
through the satellite link, it may be not easy to synchronize the timestamps with the resolution requested in 
traditional network management (e.g. at least the one of the sysUpTime in SNMP [i.l8], which is one 
hundredth of a second). GPS time source may be a solution; there is also an inherent advantage in TDM 
satellite systems where all STs receive the same downlink signal, and this could be exploited to synchronize 
ST clocks and guarantee more precise measurements. 

Nevertheless some instruments already exist for measuring IP metrics, in particular the ones specified by the two IETF 
working groups IP Performance Metrics (IPPM) and IP Flow Information Export (IPFIX). 

The IPPM working group has described a very detailed and precise framework for practical measurement of IP metrics 
[i.7], which is considered a very valuable reference also for BSM networks. For example it specifies different notions of 
metrics and different methods of collecting performance parameters samples (e.g. Poisson sampling). In particular the 
three different notions of metric can be also applied to the BSM IP parameters: 

• Singleton metrics: They are, in a sense, atomic (but not necessarily instantaneous), they represent a single 
instance of a measurement, i.e. a single delay measurement or a single instance of throughput (even if the 
throughput, for example, involves measuring the timing of a number of packets, so it is not instantaneous). 

• Sample metrics: They are derived from a given singleton metric by taking a number of distinct instances 
together; e.g. a sample metric of delays can be specified as an hour's worth of measurements, each made at 
Poisson intervals with a mean spacing of one second. 

• Statistical metrics: They are derived from a given sample metric by computing some statistic of the singleton 
values; e.g. the mean of all delay values on the sample given above might be defined as a statistical metric. 

These three notions can be applied to all BSM IP parameters in a way similar to the metrics specified by the IPPM 
working group, for this reason for each BSM IP performance parameter reference is given to the corresponding IPPM 
metric in order to have more extensive information. The following metrics are currently defined by the IPPM working 
group (not all of them are relevant for the BSM IP parameters, the relevant ones are referred in the two following 
clauses of the present document): 

connectivity (RFC 2678 [i.8]), 

one-way delay (RFC 2679 [i.9]) and loss (RFC 2680 [i.lO]), 

round-trip delay (RFC 268 1 [i. 11 ]), 

delay variation (RFC 3393 [i.l4]), 

loss patterns (RFC 3357 [i.l3]), 

packet reordering (RFC 4737 [i.l6]), 

bulk transport capacity (RFC 3148 [i.l2]), 

hnk bandwidth capacity (RFC 5136 [i.l7]). 

For the practical estimation of the performance parameters, it should be finally noted that there are protocols which 
allow to exchange measurements in standard formats, and thus give the possibility to collect data from heterogeneous 
devices from different vendors. The One-Way Active Measurement Protocol (OWAMP) RFC 4656 [i.l5] was 
developed to measure one-way performance parameters, it can measure one-way delay, as well as other unidirectional 
characteristics, such as one-way loss; in order to have good synchronization of the measurement data, the protocol 
assumes, of course, that precise time sources are available to the host performing the measurement. 

The IPFIX model [i.l9] defines a way to monitor an IP flow at one particular observation point in a network (routers, 
measurement probes or other devices) and to export the recorded IP flow data to a so-called collector by means of the 
IPFIX protocol. In a BSM network the exporters, using IPFIX terminology, may be STs and the collector a central 
NMC. For a detailed protocol specifications refer to [i.20] and [i.21]. 
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Currently the IPFIX protocol is not optimized for satellite networks, in particular it is based on a push model, i.e. the 
exporters send regularly updates to collectors; but some other issues relevant to satellite networks, such as time 
synchronization, are well considered also in the implementation guidelines [i.22], for example it is suggested that, when 
the precision provided by a time server through the Network Time Protocol is not sufficient, e.g. in the range of 
microsecond or nanosecond resolution, IPFIX devices need direct access to a time source, for example, to a GPS unit, 
which may be the case for STs. Anyway evolutions or adaptations of the IPFIX protocol may be foreseen for satellite 
networks. 

7.2 IP packet metrics 

7.2.1 IP Packet Transfer Delay (IPTD) 

IP packet transfer delay is measured as the time in transit of a packet between the ingress and egress MP, i.e. normally 
between ingress and egress SI-SAP, or equivalently across a portion of the BSM network section (e.g. across a basic 
satellite link), between MPj and MP2. It is defined for all successful and errored packet outcomes. 

IPTD is the time (t2 - 1^) between the occurrence of two corresponding IP packet reference events, ingress event at MP^ 
at time t^ and egress event at MP2 at time f2, where (t2 > t^) and (t2 - 1^) < T^,^^. If the packet is fragmented, f2 is the 
time of the final corresponding egress event of the last fragment. If (t2 - 1^) > T^,^^ the packet is considered lost. 

RFC 2679 [i.9] can be also consulted for more information. 

7.2.1 .1 Mean IP Packet Transfer Delay 

The Mean IP packet transfer delay is the arithmetic average of IP packet transfer delays for a population of interest. It is 
in fact a particular type of statistical metric for the singleton IPTD (see [i.9]). 

7.2.2 IP Packet Delay Variation (IPDV) 

The IP packet delay variation is a measure of the delay jitter across the BSM network. If IPTDj^ and IPTDjj^ are the IP 
packet transfer delays for packet n and m respectively, it is IPDV = I IPTDj^ - IPTD^^^ I, and IPDV ^ IPDV^^j^j^ for any n 
and m. 

RFC 3393 [i.l4] can be also consulted for more information. 

7.2.3 IP Packet Loss Ratio (IPLR) 

IP packet loss ratio is the ratio of total lost IP packet outcomes (namely packets which traverse an ingress MP, but not 
the corresponding egress one) to total transmitted IP packets in a population of interest. 

A packet is to be considered lost if, once traversed the ingress MP, it does not arrive at the egress MP within a given 
number of seconds (the timeout value, T^ioss)- The parameter T^^^^ is provisionally set to 10 seconds for a single satellite 
hop. 

Table 7.1 : Timeout parameter for evaluating the loss of an IP packet 



^loss 


10 seconds 



RFCs 2680 [i.lO] and 3357 [i.l3] can be also consulted for more information. 

7.2.4 IP Packet Error Ratio (IPER) 

IP packet error ratio is the ratio of total errored IP packet outcomes (failing the IP header checksum) to the total of 
successful IP packet transfer outcomes plus errored IP packet outcomes in a population of interest. 

RFCs 2680 [i.lO] and 3357 [i.l3] can be also consulted for more information: the IPPM approach makes no distinction 
and corrupted packets are counted as lost. 
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7.2.5 Spurious IP Packet Rate (SIPR) 

Spurious IP packets are packets which crosses an egress MP, without having traversed the corresponding ingress MP; 
they are erroneously routed to the wrong ST in the BSM network. 

Spurious IP packet rate at an egress MP is the total number of spurious IP packets observed at that egress MP during a 
specified time interval divided by the time interval duration (equivalently, the number of spurious IP packets per 
service-second). 

7.2.6 IP Packet Reordered Ratio (IPRR) 

In-order arrival is a property of a set of packets for which the sending packet order is preserved on arrival at the 
destination host. 

Packets usually contain some unique identifier applied at the SRC, sometimes assumed to be a sequence number, which 
is the reference for the original packet order at the SRC; this information at the DST at each packet reception gives the 
possibility to determine which specific packet is the "next expected" one. Every time a packet at arrival has a sequence 
number lower than the "next expected" one, the packet is reordered, and a reordered packet outcome occurs. 

An IP packet reordered ratio is the ratio of the total reordered packet outcomes to the total of successful IP packet 
transfer outcomes in a population of interest. 

RFC 4737 [i.l6] can be also consulted for more information. 

7.3 IP Flow Metrics 

A flow is a set of packets object of the measurement, it has to be specified and described in the so-called population of 
interest. 

Flow or throughput-related parameters try to evaluate the ability of the BSM network to carry quantities of IP packets. 
As formally defined in the next two clauses, the throughput defines the gross data transfer rate (including errored 
packets) in bits per second for a particular IP service as measured at the egress MP, and goodput defines the net data 
transfer rate (excluding errored packets). It should be noted that the throughput and the goodput measured at IP level 
may be misleading estimates of the resources available to a specific application, because they are influenced by 
bandwidth sharing policies applied at higher layers (e.g. TCP) and by overhead due to signalling and other protocol 
headers, so they have to be treated carefully. In addition throughput and goodput are always dependent on the amount of 
IP packets delivered into the network, and so it is recommended, when measuring flow-related parameters, to describe 
the traffic offered to the network (e.g. by means of the "Traffic Pattern" parameter, see clause 6.12). These issues are 
widely discussed in RFCs 3148 [i.l2] and 5136 [i.l7]. 



7.3.1 IP Packet Throughput (IPPT) 

For a given population of interest, the IP packet throughput at an egress MP is the total number of bits in IP packets 
(including IP headers) that were successfully received at that egress MP, both for successful and errored packets, during 
a specified time interval divided by the time interval duration (equivalently, the number of bits in successfully received 
IP packets per service-second). 

7.3.2 IP Packet Goodput (IPPG) 

For a given population of interest, the IP packet goodput at an egress MP is the total number of bits in IP packets 
(including IP headers) that were successfully received at that egress MP, excluding errored packets, during a specified 
time interval divided by the time interval duration (equivalently, the number of bits in correctly received IP packets per 
service-second). 



7.4 IP Service Availability (IPSA) 



The definition of this BSM IP performance parameter considers as reference the ITU definition [1]; IETF definitions in 
RFC 2678 [i.8] can be also consulted for more information. 
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The IP service is not available if IPLR exceeds a given threshold c, when measured over a minimum number of packets 
Mjjy and over a minimum interval of time T.^^. So the outage criterion can be expressed as: 

IPLR > c . 
The parameters c, M.^^, and T^^ are provisionally defined according to table 7.2. 

Table 7.2: Parameters for evaluating the outage criterion for IP service 



c 


0,75 


'Wav 


1 000 packets 


'av 


5 minutes 



The IP service is available if the outage criterion is not satisfied ( IPLR < C ). 

IP Service Availability is defined as the share of total scheduled IP service time (the percentage of T.^^ intervals) that is 
(are) categorized as available, i.e. for which the outage criterion is not satisfied. 



7.5 



Summary 



The diagram in Figure 7.1 summarizes all the BSM SI-SAP performance parameters listed in this clause, and their 
logical hierarchy. It is worth noting again that these parameters are not linked to any specific network element or 
network section; for this reason, depending on the network elements and/or services interested by a given measurement, 
these parameters may carry more general information on the overall BSM network, or more specific information. 

BSM IP Performance Parameters 

IP Packet Metrics 

IP Packet Transfer Delay (IPTD) 

' Mean IP Packet Transfer Delay 

IP Packet Delay Variation (IPDV) 

IP Packet Loss Ratio (IPLR) 

IP Packet Error Ratio (IPER) 

Spurious IP Packet Rate (SIPR) 

— IP Packet Reordered Ratio (IPRR) 

■IP Flow Metrics 

■IP Packet Throughput (I PPT) 

-IP Packet Goodput (IPPG) 

■IP Service Availability (IPSA) 



b 

■ — I 



Figure 7.1 : Entity Relationship Diagram for the BSM IP performance parameters 

in an ST (single BSMJD) 
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Annex A (informative): 

BSIVI IP performance objectives 



In the following some indications are given on the BSM IP performance parameters objectives for the BSM traffic 
classes defined in [i.3], in a way similar to what was done by ITU in [i.5] and [i.6]. The table presented in this annex 
should serve as guideline for the definition of traffic classes in a BSM network and consequently for the definition of 
the associated SD services and QIDs. These values should be intended as representative of the whole BSM network 
performance for a given traffic class, thus when performing the monitoring of these parameters, appropriate sampling 
methods should be considered (e.g. averaging performance measurements over ST populations with heterogeneous 
channel conditions, and over different time intervals). 

Comparing these performance objectives with those suggested in the ITU-T Recommendation Y.1541 [i.5], it should be 
noted that here the IPTD values have been set taking into account the long BSM propagation times, which may prevent 
low end-to-end delay requirements (characteristic of terrestrial networks) from being met. Considering the experience 
of existing voice and telephony services running over geostationary satellites, these values still seem acceptable for the 
related BSM traffic classes. 

Table A.I : Guidance for BSM IP performance objectives 



BSM IP 

performance 

parameter 


BSM traffic classes 





1 


2 


3 


4 


5 


6 


7 


IPTD 


300 ms 


400 ms 


500 ms 


400 ms 


500 ms 


1 s 


n.a. 


n.a. 


IPDV 


50 ms 


50 ms 


50 ms 


n.a. 


n.a. 


n.a. 


n.a. 


n.a. 


IPLR 


10-5 


10-3 


10-3 


10-3 


10-3 


10-5 


10-4 


n.a. 


IPER 


10-6 


10-4 


10-4 


10-4 


10-4 


10-6 


10-5 


n.a. 
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